Misc Report Menu, Export Menu, and the Merge Menu. A menu enables the
user to quickly and easily perform operations and commands, that have been
grouped together for convenience on one screen.
To use a menu, the database user chooses an operation to perform, by entering
the operation's key number shown to the left of each operation.
EXAMPLE: To select the Client panel from the Main Menu
Notice the number shown to the left of Client (in the
shaded box - Fig 2), this is the operation key. This
key/number must be entered to start the Client panel.
Press 1
Then [ENTER]
The user will now be in the Client panel.
Note, any operation keys that are numeric (ie: 1,2,3....) require a two step
process to execute. Once the number is entered, the [ENTER] key must be
pressed to execute that operation. However, if an operation key is not
numeric (ie: F7), then it is a single step operation. Just that key has to be
pressed to execute that operation.
EXAMPLE: To EXIT the Main Menu and leave the
RequestMANAGER program.
Notice the operation key to the left of EXIT
PROGRAM.
Press [F7]
The user will have left the RequestMANAGER program.
There are two operations that can be performed from the Main Menu, that are
not shown on the Main Menu. These are the Panel and Report Lists. These can
be accessed by entering 99 or 98 respectively then [ENTER] while in the Main
Menu. You will then be prompted for the definer password before you can
proceed. See the DataPerfect manual for information on the Panel and Report
Lists.
EXAMPLE: To access the Panel List from the Main Menu.
Press [99]
Then [ENTER]
The user will now see the Panel List.
Main Menu:
The Main Menu, shown below, is the first screen seen by the user after the
RequestMANAGER database starts (see Getting Started for details on
starting RequestMANAGER).
Through the Main Menu, the database user can access the main data panels
and add/change/delete/or inquire data, enter the Misc Panel Menu to access
data checking panels, enter the REPORT Menu and run one or more of the
pre-defined reports, enter the Export or Merge Menus and export (move) data
to other application programs or create a WordPerfect secondary merge file
for use in mail merge, Post data, or leave the RequestMANAGER database.
Misc Panel Menu:
The Misc Panel Menu is a collection of less frequently used data information
panels.
Information entered through any of those panels provides for data checking.
For example, by maintaining a list of valid type codes, and allowing only
those valid type codes to be used and entered, and being consistent in the use
of the codes, provides for accurate data, and would permit the user at some
future date, to analyze requests by those type code. As the data entered is
consistent
Report Menu:
The report menu, is a second level menu, that the user enters from the Main
Menu. Once entering, the user can select, the Analysis Report Menu,
List/Detail Report Menu, and Other Report Menu. Once the user makes the
appropriate choice one of the three third level menus is displayed on the
screen.
Analysis Report Menu:
The Analysis Report Menu is a third level menu, entered by the user from the
Report Menu. The Analysis Report Menu allows the user to easily analyze the
data. Included are reports such as detail and summary inventory calculations,
analysis by prov/state, type, source, product ......
List/Detail Report Menu
List/Detail Report Menu is also a third level menu, however unlike the
Analysis Report Menu, it provides no analysis function, but acts as a means
of printing selected data.
Misc Reports Menu
The final third level menu is the Misc Reports Menu. Misc Reports are reports
that don't fit into the previous report categories; analysis, or list/detail. Misc
Reports Menu includes reports for producing a covering letter, mailing labels,
or shipping sheet.
Export Menu
The export menu provides an easy avenue for the user to move (export) data
to other application programs, such as Lotus 1-2-3, Excel, Dbase. The
automated export of the following information has been provided for; client,
request and request detail both posted and non-posted.
Merge Menu
The final menu is the Merge Menu. It provides for easily exporting in the
WordPerfect secondary merge format, of the client and request transaction
files. Files created in this format are used by word processors, when
performing a mail merge.
DATA PANELS
Every data file in RequestMANAGER has its own panel. A panel is used as a
means of displaying on the screen, the information that is contained in a
particular data file. For example, the Client Information panel will display
information (name, address, phone number ....) for each client, on the screen,
one client at a time.
As shown in Fig 5 Page 13, there are five main data files; Client, Request
non-posted, Request posted, Request Detail non-posted, and Request Detail
posted Information. There are also a series of smaller data files, that are
related to the main files. These smaller files are used for data checking. For
example, the Prov/State data file contains a list of standard abbreviations for
provinces/states, which are used to check the accuracy of the information
entered by the user. A data checking field is indicated by a [] to the left of a
field. For example, the Client Information panel has 3 data checking fields
(client type, province/state, and hear-about-us). Please see Fig 6 - page 14.
The main data files are linked, the user can move from one to another. The
link symbol is indicated by a [▒]. The user could select a client, move down to
their posted request histories - choose one, then view it's data (date, type,
source, and what was sent).
The information that is displayed, one screen at a time is called a record,
while one particular piece of this data is called a field. For example, if the
Client Information panel was displayed on the screen for the client FRED
SMITH (see Fig 6), then all of the information shown makes up FRED
SMITH's record, while the city shown would make up FRED SMITH's city
field.
Data can be changed, deleted or created through a data panel. When a new
client is added, a new client record is created, including a name field, address
field, city field ...... . Should at some time the user wish to modify or change a
particular record, ie: enter a new address, then the corresponding address
field would be edited.
At anytime, while in a panel, the [F3] key may be pressed for additional
information.
Number of times F3 pressed Result
Once Specific help for that field
Twice General help
Three Function Key list
Four Function & Formula Help
If you have any questions regarding the use of, or how to move about in data
panels, please refer to the sections Navigating a Database, Entering Data, and
Using Links in your DataPerfect Workbook. Panels cont: Client Information Panel
The 1st main data panel is the Client Information panel. It is probably the
most used panel in RequestMANAGER. It is used whenever a new client is
created, or changed/deleted, as well as a convenient means of accessing
related request information (without having to know Request ID's, and
Request Detail ID's).
As shown above, in Fig 6, the Client Information panel, maintains the most
commonly used client information (name, address city ....), as well as listing
the last 5 requests created for that client. The number in the upper right
corner is the Client ID. This number is unique for each client. As clients are
created they are automatically assigned their own number. You cannot change
any information in this field, but you can in other fields in the Client
Information panel.
The street field is a variable length text field. This field will hold more than
the two lines displayed, however only the top two lines can be printed. You
must use [TAB] to leave the street field if any text has been entered, pressing
[ENTER] will just add extra lines to the address field. Additional lines added
but not displayed, will be indicated by the [] character appearing at the
bottom right of the street field.
The Client Information panel has 3 data checking fields (Client Type,
Province/State, and Hear-About-Us). Please see Fig 6 - page 14. These ensure
that the data entered is accurate. There are times when you may need to
defeat the data checking. For example, the Province/State field provides data
checking of the prov/state abbreviations entered by the user. But those
abbreviations only apply to clients from the US and CANADA. A client from
France or Poland, for example, would not have a prov/state code. To get
around the data checking - once in the data checking field, press the [SPACE
BAR] to erase any information displayed, then [ENTER] to accept no entry.
You will then be reminded that what is now in the field (no entry) does not
match any entry in the data checking file, if that is correct, press [0] to
proceed.
The information in the Phone and Fax fields can be used to dial a phone/fax
number, if a modem is attached to the computer running RequestMANAGER.
See the DataPerfect manual for details.
The comment field allows the user to enter any comments for a particular
client, up to 50 characters per client is permitted. The Comment field can also
be used to further analyze clients, if the Comment field contains only data of
the same type and format. For example, if the user wished to determine not
only how clients heard about their products but also from where? The
Comment field could contain newspaper names, operator numbers (1-800
telephone number ask for operator number), magazine ...... A report could then
be designed to analyze the combinations of the hear-about-us and comments
fields. The only requirement to do this, would be that any information
entered must always be entered the same way. ie: LA Times is not the same as
Los Angles Times or Times (While we can see that they are the same, a
computer can't). See Fig 19a & 19b.
The lower right of the Client Information panel displays unposted request
information that is related to a particular client. This window can show the
last 5 unposted request records; their transaction request numbers, when they
were received and shipped, what type of request they were, and their record
printed indicator.
The bottom left of the panel contains 2 links to other panels, the unposted
and posted detail panels. Beside each link is descriptive text that tells the user
how to access the next panel. For example, in Fig 6, to go to the unposted
Detail panel, the user would place the cursor on the 1st link, and press the []
key. Panels cont: Request Information Panel
The next main data file, is the Request Information panel. Like the others,
it's ID number is located in the upper right corner, and it shows - at the lower
right - information that is related to it. In this case, a list of material
requested. See Fig 7, Request Information Panel.
The Request Information panel uses 2 related data files for data checking,
Request Type, and Request Source. It also has fields for Received Date,
Shipped Date, Request Type, Request Source, and Select.
Received Date is the date the client's request was received. The Shipped Date
is the date the request is filled (shipment date). Enter the Shipped Date only
if different from the date the mailing labels and shipping sheet are run. When
the Mailing Labels/w detail and Shipping Sheet reports are run, the report's
run date will be automatically entered into the Shipment Date field of any
that are records printed, if the field was empty when the report was run.
The Select field allows the user to select a record(s) for printing (the user can
also de-select a record that has been previously selected for printing). When a
record is created, it is automatically selected (a [*] is placed in the select
field). If the user wishes to de-select it, simply pressing the space bar while in
the Select field will erase the [*] character.
When the reports; Mailing Labels w/Detail, and Shipping Sheet are run, they
look for, and print only those records that have been selected. Records that
have been printed will have a print indicator beside the select field. If a
record was printed by Mailing Labels w/Detail report - a [L] will be
displayed, by Shipping Sheet report - a [S] will be displayed, and by both
reports a [√] will be displayed. Only those records that have been printed by
both reports can be posted, a [√] is displayed in the Status field.
The bottom left of the panel contains the link to the detail panel. Beside the
link is descriptive text that tells the user how to access the next panel. For
example, in Fig 7, to go to the Detail panel, the user would place the cursor on
the link, and press the [] key. This client has only 1 one detail line for this
transaction. The detail window can show up to 8 lines of detail.
Posting moves data from the un-posted to the posted Request Information
panel. Posting data regularly will maintaining optimum data entry speed.
Only data that has been posted can be analyzed by the analysis reports and is
used in inventory calculations. The Request Information unposted and posted
panels, contain the same basic information, but the posted panel does contain
the additional field of Posted Date. See POSTING later in this guide. Panels cont: Request Detail Information Panel
The Request Detail panel records the product requested for each request
record. As each panel records a single product, there may be more than one
Request Detail panel that relates to a particular request record. Please see Fig
8, Request Detail Information Panel.
The ID number for the panel is in the upper right hand corner, and cannot be
edited by the user. This number is created automatically as new records are
added.
Entries in the Quantity field are subtracted from the amount in the Quantity-
On-Hand field in the Product panel. This running total maintains a inventory
balance for each product.
Note the quantity, in Fig 8. Quantities default to a positive number, you do
not have to enter the plus sign. However, should you wish to enter a negative
quantity, then you must use that sign. When entering the negative sign, you
may enter it either in front of, or behind the number; RequestMANAGER
will then, for consistency purposes, format the number with a trailing
negative sign.
As with the Request Information panel, the Request Detail panel has a posted
counterpart, the Posted Detail panel. When data is posted, it moves from the
unposted Request Detail panel to the posted panel. It is important to perform
POST on a regular basis. Posting often will keep the data in the unposted file
at a minimum, maintaining optimum data entry speed. Only data that has
been posted will be used by the analysis reports and for inventory
calculations. DATA CHECKING PANELS
RequestMANAGER uses 6 data checking files to check the accuracy of
information entered by the user. The codes contained in these data checking
files are also used as 'keys' to analyze the data. For example, by using a
consistent coding for prov/state abbreviations, the user can analyze the
request data and determine the locations and patterns of client requests. See
Fig 15. The panels used to display the data checking information in
RequestMANAGER are:
Client Hear-About-Us Panel
The Client Hear-About-Us panel, one of the Client panel's data checking
files, is used to maintain a list of allowable codes of how the client heard
about the requested product. Codes such as; PAPER, RADIO, ADV (for
advertisement), are possibilities. Used for analysis reports - see Fig 19a & 19b.
Client Prov/State Panel
The Client Prov/State panel, the second Client Panel data checking file,
contains generally accepted abbreviations for provinces and states. Used for
analysis reports - see Fig 15.
Client Type Panel
This panel, maintains the list of allowable client types. Suggested types could
be; INDV = individual, GOVT = federal government, MUNI = municipal
government .......
Product Panel
This data file is used by the Detail panels, to maintain a standard list of
product requested. Used for analysis reports - see Fig 16.
Request Source Panel
Used by the Request panel, this file maintains a list of sources of where the
request records originated. Such as PHONE, MAIL, WALKIN...... Used for
analysis reports - see Fig 17.
Request Type Panel
Used by the Request panel, this file maintains a list of request types. Such as
PROMO = promotion, RECAL = product recall, REG = regular .... Used for
analysis reports - see Fig 18.
User Panel
This panel contains the information (Login ID, Password, Name, Location)
about the users, the users who are authorized to use RequestMANAGER.
Entry to this panel is restricted. To gain entry, the supervisor password must
be entered. See your RequestMANAGER registration card for the Supervisor
password.
Initially there is only one entry, Quick Entry, in this panel. Quick Entry
allows initial access to RequestMANAGER, before passwords are created for
the users. AFTER the user's information has been created, delete the Quick
Entry record. AT NO TIME, delete the Quick Entry without setting up
additional passwords - subsequent access to RequestMANAGER may be
impossible.
While the use of Login ID's and passwords is highly recommended, this
feature can be disabled if desired.
To disable user password checking:
■ From the Main Menu, use command 99 to select the Panel
List. Enter the definer password when prompted, to gain
access to the Panel List.
■ With the Panel List displayed, select System Operations
press [SHIFT-F9].
■ Enter the definer password, see the registration card.
■ Select option [B], User ID panel.
■ The currently selected User ID panel name will be
highlighted, press [F1] to cancel, then press [F7] to save. REPORTS
The report functions in RequestMANAGER are both powerful and versatile.
Using reports, the user can print data (to the screen, printer, or file). There
are 28 different pre-defined reports in RequestMANAGER, more can be
added.
Select a Report
To select a report to print, the user first chooses Report Menu on the Main
Menu, then selects a report type (Analysis, List, or Other) on the Report
Menu, then selects the desired report. The Report Screen is then displayed.
The Report Screen, shows the user the default settings for the selected report,
where the report is to be printed (screen/printer/file), any search conditions,
sort directions, ......... . For most instances the default settings will be correct.
If desired however, the settings can be temporarily changed by the user. When
the information displayed is satisfactory, the user, would press [SHIFT-F7] to
begin the report.
When the report begins, the Report Selected OK screen is displayed. This
screen shows the user which report will be printed, and gives the user a
chance to cancel if desired. For some reports, the user is also presented with a
ID range to select (to narrow down the amount of data to print).
The starting ID should always be less than the ending ID. For example: a
valid ID range would be, 1 to 100, A to Z, 10 to 10, C to D .......
but 12 to 10 would be an invalid range. If an invalid range is selected, the
report will print (just the report header), but without any data.
The ID range request has built in logic.
■ If nothing is entered for starting and ending ID's:
For numeric ID's a range of 1 to 999999999 is assumed.
For text ID's a range of A to Z is assumed. For example, the
Product ID is a text ID. Pressing [ENTER] for both the starting
and ending ID's in Fig 9b, got the range shown in Fig 9c. If
however, an ID had been created with a leading number
(ie: 1WIDGET), then it would not be picked up by the range A
to Z. DataPerfect sorts numbers before letters. If you have text
ID's which start with a number, use the starting range of 1
(ie: 1 to Z).
■ If an entry is made for either the starting or ending ID, but not both:
It is assumed that the user wants the starting and ID's to be the
same, ie: select only one record for printing. For example, in the
report shown in Fig 9a-c, if the user wished to select only those
records which contained the product, WIDGET. Then typing
WIDGET in either the starting or ending ID fields, and pressing
just the [ENTER] key for the other field, will select the range,
from WIDGET to WIDGET. Or, in other words, select only the
records that contained the product WIDGET.
■ Of course, the user can also manually enter the starting and ending
ID range as well.
Once the ID range is entered, the user is presented with the ID Range OK
screen. This shows the user the ID range selected, and gives the user the
opportunity to stop or accept the report. The report will then print.
Dpprint Printer Program
All the reports (except mailing labels) in RequestMANAGER, should be
printed with DPPRINT running. DPPRINT is a memory resident printer
program included with DataPerfect. DPPRINT includes printer definitions
for specific printers, and allows RequestMANAGER to print with bolding
and underlining. DPPRINT also handles form feeds at the end of a print job.
If DPPRINT is not loaded, when a report is run, the user will have to press
[FORM FEED] at the end of a print job, to advance to the top of the next
page, and on laser printers, to print the remaining information held in the
printer's memory.
See your DataPerfect manual for details on loading DPPRINT.
If RequestMANAGER is being run on a network, then DPPRINT must be
loaded before starting DataPerfect. As soon as report is begun in
RequestMANAGER/DataPerfect, a print header is sent to the printer. From
that point, until the job is finished (which can take minutes for large/long
print jobs - or where there is a large amount of data to sort) the printer is tied
up. The printer would be considered IN USE by the network, even though it
might be printing only a small percentage of the time. During this time the
printer will be unavailable to the rest of the network. Not very efficient. To
get around this, DPPRINT acts as a print spooler. Taking the output for a
print job, storing the information, then sending it to the printer when the
report is finished.
If however, you are printing mailing labels on a dot matrix printer, then it
might be advisable not to load DPPRINT. Some dot matrix printers are not
reliable when printing labels, they jam, or the labels can go askew. As
DPPRINT stores the entire print job, then sends it to the printer, any
interruption in the print job, say to un-jam a printer, will cause DPPRINT to
immediately re-send the job, from the beginning, as soon as the printer is
turned back on-line, or if the computer was restarted as soon as DPPRINT is
run again.
Add a New Report/Change an Existing Report
While RequestMANAGER comes with a selection of reports, there are
instances where the user might wish to create a new report, or change an
existing one. See your DataPerfect Manual for complete details, a outline
follows.
To add a report (or change an existing one). You must use the definer
password shown on your RequestMANAGER registration card.
To add a report:
■ From the Main Menu, use command 99 to select the Panel
List. Enter the definer password when prompted, to gain
access to the Panel List.
■ With the Panel List displayed, select the panel, you wish to
base the report on.
■ With the selected panel displayed, select Print/Export, press
[SHIFT-F7].
■ Move the cursor to Built-In Reports, press [INSERT].
■ Follow the procedures in your DataPerfect Manual and Work
Book, to create a new report.
■ If you wish the new report to be displayed on a menu, the
menu system must be changed. See your DataPerfect manual
for details.
To change an existing report:
■ From the Main Menu, use command 98 to select the Report
List. Enter the definer password when prompted, to gain
access to the Report List.
■ With the Report List displayed, select the report, you wish to
change.
■ Follow the procedures in your DataPerfect Manual and Work
Book, to change an existing report.
■ The menu system must be changed to recognise any changes
made to a report. See the DataPerfect manual for details.
REPORTS - ANALYSIS
The Analysis Report Menu is one of three third level report menus, through
which the user can select a analytical report. Please see Fig 10.
Most of the analysis reports prompt the user to enter a ID range to narrow
down the search for data. If the user wishes to further narrow down the
selection, to a particular period, prov/state/, type, source, ...... then the user
must change the report's search settings. Please see your DataPerfect manual
for details.
If you have more than one year of request records entered, and only want the
current year printed, the user must change the search conditions, so the report
will only look for a specific range of Received and Shipped Dates. If the
search conditions are not changed to select only a particular year, then
reports that tabulate data in columns by months, would group data from like
months but different years together; ie: add July 93 & July 94 together.
The analysis reports fall into two categories; quantity totalling (Inventory
Detail and Summary) and record totalling reports (the other 10 reports).
Inventory Detail and Summary reports will calculate a inventory balance for
a range of products entered by the user, by adding together the quantity field
in all the request detail records. These reports show the actual movement in a
product. The other reports, show the number of times a product was
requested. This can be different from it's quantity. For example, a client
might request 8 brochures for the product WIDGET. The inventory reports
will show the movement of 8 brochures shipped out. All other reports will list
the movement as 1 - the number of times the product was requested. While
every application will be different, normally the mix of quantities shipped
will be weighed towards single units (ie: most clients will want a brochure,
but a few may want more). As the number of records increases, the number of
records shown in these reports will also approximate the quantity shipped and
the number of clients.
Inventory Detail by Product Report
This report calculates the inventory for the product range entered by the
user, listing all transactions. Normally used for audit purposes - ie: if you
want to know what transactions are used in calculating a product's inventory
balance, or as a check of the balance in the product panel. This report
requests the user to enter the starting and ending Product ID's, so the user
should have those IDs handy when the report is run.
This report is a detail report, it lists all lines of data - without any summary.
If you have a large amount of data, the printout can be long. See Fig 11.
Inventory Summary by Product Report
This report has the same basic format as the previous report, Inventory Detail
by Product. However this report only prints the totals for each product. The
report requests the user to enter the starting and ending Product ID's, so the
user should have those IDs handy when the report is run. This report would
most likely be used for audit purposes, to find an error in data. It goes
through each line of request detail and calculates an inventory balance -
useful for comparing with the inventory on hand field in the product panel.
See Fig 12.
Note (Fig. 12) there is a mix of positive and negative inventory quantities. A
negative quantity might indicate that there was an error in entering.
Indicating a need to run the Inventory Detail report, and then reconcile the
inventory.
#Requests per Month (Workload) Report
Requiring no input (ID's) from the user, this report tabulates the number of
requests in columns. This report, see Fig 13, is calculated on the Received
Date. This report is useful in comparing the workload (#requests) from one
month to another. The data selected can be further narrowed down by
changing the search conditions. See the page 25.
#Requests and Average Response Report
This report displays both the number of requests (top line) and average
response time (bottom line - in days) in tabular form by month. This report,
see Fig 14, is calculated on the Received Date. Average response time is
defined as the average difference between the date the request is received
and the date the request in shipped,
for all the requests shipped during a particular month. Notice that there is
difference between the number of requests in Fig 14 & 13. Records without a
valid date in the Received Date or Shipped Date fields are ignored. As the
difference is not significant, one would have a high level of confidence in
the response times.
This report can help to spot problems in processing requests. Hypothetically, a
request received should be processed and shipped within a few days, any
longer and there might be a problem. An order of magnitude longer, and it
might indicate a staff attitude problem - after all if a potential client was
interested enough in your product to contact you, then there is an obligation
(and it's smart business) to fill the request as fast as possible.
#Detail by Product per Month Report
This report shows the number of requests for each product in the range of
products selected by the user. See Fig 14a.
#Requests by Prov/State per Month Report
The #Requests by Prov/State per Month report, shows in tabular format, the
number of requests, for each province/state, shipped by month. This report,
see Fig 15, is calculated on the Received Date.
This report can be used to help show some useful comparisons, prompt some
interesting questions. For example, the report will show if there is a
particular region or province/state which is requesting the most. Conversely
that also shows a region which is requesting the least. Why? Does the pattern
of requests compare to sales? ie: is the distribution the same by region or
month. Is there a pattern in requests; by month increasing or decreasing (do
our products need updating), seasonal changes ....... How do these requests
compare to our advertising costs?
This report requires the ID range be entered by the user, the data selected can
be further narrowed down by changing the search conditions. See the
DataPerfect manual for details.
#Detail by Product & Prov/State per Month Report
This report requests the user to enter the Prov/State ID, so the user should
have that ID handy when the report is run. This report shows in tabular
format, the number of requests by each product requested, for a particular
province/state, shipped by month.This report, see Fig 16, is calculated on the
Shipped Date.
This report expands on the information presented in the previous report; the
user could select a particular location that is of interest, then use the #Detail
by Product & Prov/State per Month report to determine what makes up their
requests. This report can show if client's requests are changing by time or by
product.
#Detail by Prov/State & Product Report
This report is the reverse of previous report - this sorts first by Prov/State,
listing what product each location requests by month. See Fig 16a.
#Requests by Source per Month Report
The #Requests by Source per Month report, shows in tabular format, the
number of requests, for each request source, for request's shipped by month.
This report, see Fig 17, is calculated on the Shipped Date. This report will
show you how the client gets in contact with you, and if it varies from period
to period.
#Requests by Type per Month Report
The #Requests by Type per Month report, shows in tabular format, the
number of requests, for each request type, for request's shipped by month.
This report, see Fig 18, is calculated on the Shipped Date. This report will
show you what are the types (kinds) of client requests, and if they vary from
period to period.
The final two analysis reports compare the Hear-About-Us field and either
the Prov/State field or the Comment field in the Client Information Panel.
See information about using the Comment field for analysis on page 15. For
the Hear-About-Us analysis reports to provide accurate/reliable information,
the clients must be asked and respond, as to how they heard about the
products and where. A low response rate might adversely effect the accuracy
of the data.
Hear-About-Us by Prov/State Report
This report compares how a client heard about you versus location. What is
the most effective means of reaching your clients? This report can tell you.
For example; how can one know the most cost efficient means of contacting
potential clients? Compare the relative response rate for different advertising
means (ie:Newspapers x,000 Magazines y,000 Radio z,000 requests ....) with
the actual dollars spent. Do they all have the same cost per thousand requests?
Are some better than others? Are certain locations (prov/state) more or less
cost efficient. By pinpointing specific locations, and methods of contact, can
dramatically effect one's advertising efficiency.
The report, see Fig 19a, shows the number of clients for each Hear-About-Us
code, grouped by prov/state. For example, Fig 19a shows us that 5 times more
clients are reached (or report they are) by advertising in Maryland (code MD)
than North Carolina (code NC). ..... Why?
Hear-About-Us by Where (Comment) Report
This report uses the information entered into the Comment field to further
analyze the Hear-About-Us field. See information about using the Comment
field for analysis on page 15. It is important to be consistent when entering
data in the Comment field. Please see Fig 19b. It can be seen that the
Montreal newspaper, La Presse, was entered 3 different ways. These would of
course have to be added together (or the information changed in the Client
Information panel, and the report run again) to calculate it's relative
effectiveness.
This report shows the number of clients, for each Hear-About-Us code,
grouped by the information in the Comment field - in this case (Fig 19b)
newspapers. As can be seen in this example, the newspapers La Presse, Le
Soleil, and Journal de Montreal, all Quebec newspapers have the highest
number of responding clients. People in Quebec seem to like our products ....
Why not others?
Note; in the examples shown, Fig 19a & 19b, the clients weren't asked how
they heard about a product. Because they volunteered, the response
percentage (#Hear-About-Us responses for a particular location divided by
the number of clients for the same location) varied wildly, from 2% to 49%. A
high level of confidence in the data can only be achieved when the variation
in the response percentage is minimal. Always spot check the data to verify
this.
REPORTS - LIST/DETAIL
The List/Detail Report Menu is the second of three third level report menus,
through which the user can select a list or detail report. Unlike the Analysis
Report Menu, the list/detail reports provide no analysis function, but act as a
means of printing selected data. Please see Fig 20.
To narrow down the data (to search through and print), these reports prompt
the user for an ID range. For example, when printing the Client List report,
the report prompts the user for the starting and ending Client ID's to print.
As the report requests the user to enter an ID range, the user should have
those ID's handy when the report is run.
Of course, as in the Analysis reports, the user may further narrow the data by
changing the search conditions. For example, if the user wished to print the
Client List report but only wanted the clients printed who resided in a
particular Prov/State, let's say British Columbia (which has a code of BC) .
Then the user would change the search conditions, to look only for a range
starting from BC and ending with BC. For further details on changing the
search conditions, please see the DataPerfect manual.
As all of these reports have the same basic format, perhaps the easiest/best
way to describe (what ID the reports request?, what is the result of running
each of the List/Detail reports?) is to present this information in a tabular
format, then go into more depth on a few of these reports. Please see the
table, on the next page.
REPORT ID
REQUESTED RESULT Client Client Lists clients Client by Type Type Lists clients by type Client Hear-About-Us H.A.U Lists hear-about-us codes Client Prov/Sate Prov/State Lists prov/state codes Client Type Type Lists client type codes Product Product Lists product codes Request Request Lists request records Request Detail Request Lists request rec w/detail Request Source Source Lists source codes Request Type Type Lists type codesTable 1:List/Detail Reports
As seen above, these reports cover both the main data files (Client, Client by
Type, Request, and Request Detail) and the smaller data checking data files
